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(57) Abstract 

A method and system for creating and interpreting forms having 
embedded interpretable code. The form may be transmitted across a 
global computer network and received at a remote location. Data 
fields included on the form are filled out, either fully or partially 
and either electronically or manually, and thereafter sent to a central 
location. The embedded interpretable code is accessed for form 
interpretation. Interpretation of the code allows the form at the central 
location to be processed for data extraction. Sending the form to the 
central location may be done through mail, fax, electronic mail or 
via HyperText Transfer Protocol (HTTP) over the global computer 
network. 
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AUTOMATED FORM GENERATION INTO AN ADVANCED PAGE LAYOUT 
FORMAT WITH EMBEDDED FIELD DEFINITIONS 

Background of the Invention 

Field of the Invention 

The present invention relates to automated form generation and interpretation. 
More specifically, it relates to generating a page layout format form that can be 
completed electronically, manually or a combination of manually and electronically, 
and then be automatically interpreted by a computer. 

Description of the Related Technology 

In the burgeoning area of networking, particularly a global computer network 
such as the World Wide Web or Internet, the exchange of information has been 
increasing at a tremendous rate. However, to date nearly all of the focus in 
development of the Internet has been put into delivering content to end-users. As a 
result, the Internet provides an excellent way for delivering graphics, text, video, sound 
and more, and such technology is constantly improving. Yet, despite the fact that the 
Internet is a great source for collecting data, development has been relatively weak in 
that area. 

Collecting of data is enhanced by interactivity and because of reach and 
availability to so many users around the world. There are many reasons for collecting 
data over the Internet; perhaps the most compelling being e-commerce. In any 
commercial transaction, data must be exchanged to perfect the deal. Payment, 
shipping, ordering and personal information must be received to complete the electronic 
transaction. Similar types of data are gathered for Internet-related services and for 
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entities that simply gather information on-line. For each of these, forms must first be 
filled out or completed by the end-user so as to collect the needed data. 



The authors of HyperText Markup Language (HTML), a computer language 
5 used for defining an electronic page viewable in an Internet web browser, provided 
mechanisms to allow programmers to create web-based forms and the ability to enter 
information. These authors also defined mechanisms for programmers to be able to 
capture the data from these forms. HTML programmers have taken advantage of these 
mechanisms to create many of the forms that are in use today on the Internet. 

10 

The disadvantage of using HTML for Internet based form processing is that the 
skills of a programmer must be employed to perform all of the necessary functions, 
from creation of the form all the way through validation and collection of the data. For 
instance, in form creation, the skills of a programmer with knowledge of computer 
1 5 languages, such as HTML and Java, is needed. This is a costly procedure requiring a 
person with a very specialized expertise. 

Form data typically requires validation before collection. Without validation, 
the collected data may contain a large number of errors, thereby ultimately defeating 

20 the purpose. To perform validation checks on the data, again, the high level skills of a 
computer programmer are needed. Client-specific scripting programs can be written 
that perform certain data validations, such as range checking, field length enforcement, 
character level type checking, etc. However, a further problem can arise in that some 
web browsers are not compatible with certain scripting languages. Also, if script is 

25 called from a server location referenced by a universal resource locator (URL), 
feedback delays are often experienced. Similar problems are encountered in a final step 
of copying data from the form fields and into a database. 

Furthermore, when data needs to be collected from both electronic sources and 
30 from paper sources, a system is often put in place to handle one of these sources with 
the other handled as an after-thought. The other data source may become a significant 
source of problems as adaptation of the original system is attempted. In some cases. 
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two disparate systems are put in place to accept data - one system for electronic forms 
and one for paper forms. In such cases, a significant amount of work is duplicated as 
the form undergoes design for both paper and electronic filling. Also database 
connections must be set up for both systems. Usually separate servers are also required 
5 to handle the data from these different sources. This duplication of resources 
significantly increases the cost of collecting the data. 

A solution is desired that eliminates the need for a programmer to generate 
client- specific programs for form creation and interpretation. It is desirable that 

10 through menu-driven tools of a software application, a user can create a form having 
embedded coding suitable for both electronic and paper forms. The form coding would 
be used in a form processing system, including identification, validation and 
interpretation of data, and would eliminate the need for client-specific scripting 
programs. Submittal of forms would be done on-line without the need for scripting 

15 programs that currently are necessary to perform the noted processing features. 



Summary of the Invention 

20 The present invention provides a method and a system for a layperson to create 

electronic forms with embedded interpretable codes without the necessity of 
programming in a computer language. The user only needs to become familiar with the 
menu-driven tools of a software application in order to create forms that may be used in 
a data processing system, such as a data capture system. The form may be submitted 

25 for interpretation via mail, Email, HTTP or fax. The forms may be created using page 
layout formats such as Forms Data Format (FDF) or Portable Document Format (PDF) 
that can be viewed and filled out while in a web browser. Embedded coding can be 
added to these formats and the need for scripiing of HTML-based forms is thereby 
negated. The method and system are integrated so as to permit submittal of forms and 

30 data to a central location for data processing using various modes including, fax. postal 
mail, through HTTP via a global computer network and via electronic mail. Only one 
system is needed to support all modes of submittal. 
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One aspect if the invention includes a method of creating and interpreting 
forms, comprising generating a page layout format form having embedded interpretable 
codes, transmitting the page layout format form a plurality of times across a global 
5 computer network, receiving the transmitted page layout format form at a plurality of 
remote locations from the global computer network, sending more than one completed 
form to a central location, wherein at least a first one of the received forms has been 
completed electronically and at least a second one of the received forms has been 
completed manually, and automatically interpreting the completed forms by accessing 
10 the embedded interpretable codes. 

An additional aspect of the invention includes a method of producing a form 
with embedded codes, comprising generating a page layout format form, embedding 
interpretation codes into the page layout format form resulting in an automatically 
15 interpretable form, transmitting the automatically interpretable form .across a global 
computer network to a plurality of remote locations, and providing the automatically 
interpretable form for completion at the remote locations, wherein each of the forms is 
configured for being completed electronically, being completed manually, and being 
completed at least partially electronically and at least partially manually. 

20 

Another aspect of the invention includes a method of creating and interpreting 
forms, comprising generating a page layout format form configured for being 
completed electronically and being completed manually so as to permit form 
completion, transmitting the page layout format form across a global computer network 
25 to a plurality of remote recipients, providing completion information to the plurality of 
page layout format forms received by remote recipients, sending at least one 
electronically completed form and at least one manually completed form to a central 
location, and automatically interpreting the entered information on the completed 
forms. 

30 

Yet another aspect of the invention includes a system for handling page layout 
forms, comprising a central computer, a software program executing on the central 
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computer and being configured for interactively creating a page layout format form' 
having embedded interpretable codes, wherein the page layout format form is 
configured for being completed electronically, being completed manually, and being at 
least partially completed electronically and partially completed manually, a 
5 communications device associated with the central computer and being configured for 
sending the page layout format form across a global computer network, and a remote 
computing device configured for receiving the transmitted page layout format form and 
for at least partially completing the page layout form electronically. 

1 0 One more aspect of the invention includes a system for creating and interpreting 

forms, comprising a central computer comprising a software program executing on the 
central computer and being configured for interactively creating an advanced page 
layout format form having embedded interpretable codes, wherein the advanced page 
layout format form is configured for being completed electronically and being 

15 completed manually, "a communications device configured for sending the' advanced 
page layout format form across a global computer network to a remote recipient, and an 
interpretation program executing on the central computer being configured for 
receiving a completed form and being configured for automatically interpreting the 
completed form, and a remote receiver configured for receiving the transmitted 

20 advanced page layout format form. 



Brief Description of the Drawings 

25 Figure 1 is a top level functional diagram of the system of the present invention. 

Figure 2 is a flow diagram of the submit on-line function shown in Figure 1. 
Figure 3 is a diagram of a form designer process for the designer shown in 
Figure 1 . 

Figure 4 is a diagram of a form reader process for the reader shown in Figure 1 . 
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Figure 5 is a diagram of a form verifier process for the verifier shown in 
Figure 1 . 

Figure 6 is a diagram of a PDF+Forms format process performed by the system 
of Figure !. 

5 Figures 7A and 7B are a flowchart of a process for exporting a PDF form as 

described in Figure 6. 

Figure 8 is a collection of exemplary screen displays or portions of screen 
displays while exporting a form to the PDF format. 

10 

Detailed Description of the Preferred Embodiments 

The following detailed description of the preferred embodiments presents a 
description of certain specific embodiments of the present invention. However, the 
15 present invention can be embodied in a multitude of different ways as defined and 
covered by the claims. In this description, reference is made to the drawings wherein like 
parts are designated with like numerals throughout. 

This description incorporates by reference U.S. Patent No. 5,943,137 entitled 
20 Unified Method Of Creating And Processing Fax Forms and U.S. Patent No. 5,555,101 
entitled Forms Creation And Interpretation System. 

The following description begins with a general overview of the invention in 
Figure 1 and then details the major components or component steps in succeeding 
25 figures. 



-6- 
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Referring to Figure 1, a top-level process 100 embodying the present invention 
will be described. Users can create a page layout format form from the beginning using 
5 a form designer 102 capable of electronic storage. (One example of a form design tool 
that generates forms is called TELEform, which is available from Cardiff Software.) 
Users can also scan a paper form (of potentially unknown design origin) and create 
fields within designer 1 02 that correspond with the locations where users would fill out 
the paper form that was scanned. The designer 102 will be further described in 
1 0 conjunction with Figure 3 . 

When the form design and configuration is completed or the paper form is 
scanned into the designer 102, the form can be exported to another format, such as 
Forms Data Format (FDF) or Portable Document Format (PDF) by selecting an export 

15 utility 104 from a form export menu. This may be done using an export conversion 
tool, such as Acrobat Distiller or Acrobat PDF Writer, or through a low-level program 
that interfaces with the application protocol interface (API) of PDF in the case of a PDF 
export, for automatic generation of the PDF form. The choice can be made available as 
an export option, which may be selected at the time of export. In other embodiments, 

20 other page layout formats may be used, such as an advanced page layout format. The 
remainder of the description will refer to export of a PDFform. 

Once in the PDF format, a PDF form can be opened in a viewer capable of 
reading PDF files, such as Adobe Acrobat Reader 4 or Adobe Acrobat 4. The PDF file 

25 will contain the precise look of the original form from the designer 102 or the scanned 
paper form. The form fields of the PDF form will be overlaid on the designer form so 
that they may be filled out. The form can then be submitted on-line at a function 122; 
that is. while the user is connected to a networking system capable of data transfer, such 
as a global computer network. One example of a global computer network is the 

30 Internet. 
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Deployment of the PDF based export of the form and data is similar to HTML 
based export of the form. However, unlike the HTML export, users are required to 
have a PDF viewer to open and fill out the form. 

5 To begin the process using the created PDF forms, those PDF forms must be 

transmitted to a user at a remote location (the person or entity that is destined to fill out 
the form) so that they may be completed or filled out. The present invention provides 
at least two methods, one off-line and one on-line, in which a PDF form can be 
received. To permit users to fill out forms off-line, a user using electronic mail 1 1 6 can 

10 receive the PDF form. From there, the form can be viewed in a PDF viewer 118 and 
filled out. Also, the user can print the form and fill it out with hand printing or 
handwriting. The other method, if chosen by the user, is to fill out the PDF form on a 
visual display screen, either fully or partially, while it is displayed by a web browser 
108. However, whether received via Email 116 for off-line completion or from web 

15 browser 108 after being completed on-line, the PDF form can be submitted via Email 
120. 

After receiving the transmitted form and filling it out, the user submits or sends 
the PDF form to a central location for further processing. The present invention 

20 provides many methods for submitting the PDF form and data. In one embodiment, the 
three main paths for submittals are to submit on-line, submit via Email using protocols 
such as POP3, MAPI or SMTP, and to print the PDF form and either fax it or send it 
via a mail service, for example, the user may be given choices in the export setup 
dialog. The user may also be given the option of selecting "auto-detect", where, the 

25 system is programmed to detect, based on certain configurations, which method should 
be used for submittal. In one embodiment, 'submit on-line' is the default. 

If the user should either submit on-line 122, print and fax 1 10, or print and send 
1 12, the PDF form is first stored on a web server 106. The PDF form is callable such 
30 that when a specific URL, which specifies the physical location of the PDF form, is 
entered in the web browser 108, the viewing tool selected is executed in web browser 
108 and the PDF form is received therein. After filling out the form, either fully or 
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partially, the user then decides whether to submit on-line 122, print and fax 110, or 
print and send 112. If the user decides to print and fax 1 1 0 the filled out PDF form, the 
user prints the form to a printer and faxes the printed form to a specific destination. If 
the user decides to print and send 1 12 the filled out PDF form, similarly, the user will 
5 print the PDF form to a printer. But instead of faxing the PDF form, it is sent to the 
specified destination where it is scanned for electronic submission to a reader 128 such 
as a TELEform reader. The reader will be further described in conjunction with 
Figure 4. 

10 Another option that the user has is to Email 120, such as using any of the 

protocols noted above, the PDF form on-line through a server, which is used as an 
Email handler 124, and on to an Internet server 126, such as a TELEform Internet 
server. Yet, another on-line method for submittal is to post the form data to a server 
data handling program identified by a universal resource locator (URL), such as a 

1 5 Common Gateway Interface (CGI) program, and the submit the data on-line 1 22 to the 
Email handler 124 or to a directory file. From there, PDF form and data is sent to 
Internet server 126. 

Depending on the submittal method, different processes may be used to obtain 
20 the form data. In one embodiment PDF form, which is printed and faxed 1 1 0 r will be 
transmitted as an image to the reader 128. The reader 128 identifies the form type 
received and matches the type to a form template. The form template comprises a 
plurality of fields, each having at least one attribute. Some attributes may be position 
information or field name, type, location or size. Using the form template, the reader 
25 128 reads the information on the form. Such information may include machine-printed 
characters, hand-printed characters, check marks, filled bubbles, circled responses, 
handwriting, and other markings. 

Similarly, a PDF form that is printed and sent 112 is later scanned 1 14 so that 
30 an image may be transmitted to the reader 128 for processing. PDF forms and data that 
are sent via Email 120 or submitted on-line 122 to the Internet server 126 are ultimately 
gathered by the reader 128 for processing. 

-9- 
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Whether the form is received by the reader 128 through on-line submittal to the 
Internet server 1 26, from the fax 1 1 0 or via the scanner 1 14, the data can be put through 
a verifier 1 30 that applies a consistent set of validations. Thus, no matter how the data 
5 arrives, it will undergo the same logical tests for recognition accuracy. In some 
instances, based on system configuration and PDF form design, the verifier 130 may be 
bypassed. If necessary, data sent to the verifier 130 will be modified in the reader 128 
if found to be in error. But regardless of whether or not the data is modified, and 
regardless of whether the verifier 130 is bypassed, the data may be exported to a 
1 0 database 1 32. The verifier 1 30 will be further described in conjunction with Figure 5. 

Submit On-line 

1 5 Referring to Figure 2, the operation of the web browser 1 08, the submit on-line 

function 122 and Email from a client 120 to an Email handler 124, i.e., submission on- 
line from web browser 108 as shown in Figure 1, will be described. When a user 
presses the submit button 202 after completing a PDF form on-line, one of two methods 
is used to send the form and data if the user has configured the form to submit 'Text 

20 with/PDF'. 

The method is determined at a decision state 204. One method is to send the 
form via Email. If this option is selected the form is sent via an Email protocol, such as 
MAPI 206, to the Email handler 207. 

25 

The second method is to post the data using a universal resource locator or URL 
at state 208. Here the data is formatted at state 2 1 0 by a computer program, such as a 
TELEform Internet Solution available from Cardiff Software. Once formatted, the data 
is Emailed via an appropriate Email protocol, such as SMTP mail 218, to the Email 
30 handler 207, or it is written to a file directory 216. Data, which is written to file 
directory 216 is polled and collected by a directory search service 217, such as that 
included in TELEform Internet Solution, for processing. The decision to write to a file 

-10- 
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directory 216 or send via SMTP mail 218 is configured into the system according the 
needs of the user. 



5 Designer 

Referring to Figure 3, a form designer process for the form designer 102 will be 
described. The form designer 102 enables the user to create and configure new forms at 
block 304 or to modify existing forms at block 310. New forms are created using the 

10 form designer's tools and objects. In one embodiment, new forms may be of at least 
two form types. One such form type is labeled the traditional form 306. The traditional 
form 306 includes four standard cornerstones and a Form ID Block. A second form 
type allows versatility in identification and is termed a VERSlform 308. The 
VERSIform 308 includes four identifying marks which the user can select. These 

15 marks include but are not limited to small squares, circles and triangles. An identifying 
number may also included on this form type. 

Existing forms 310 may also be modified using the form designer 102. Existing 
forms 310 are modified from a form image. This image may be in existence or 
20 generated by scanning a form 302 into the designer 102. Forms already created in the 
form designer 102 and exported may also be imported into the designer 102 for editing 
and re-export. 

Once a form exists in designer 102. it may be exported at block 312 in multiple 
25 formats, depending on the users needs, or it may be printed. Some of the export 
formats, selected from a 'Export a Form* dialog box. include TELEform, Adobe PDF 
318, and HTML 316. 

Forms are created with embedded interpretation codes that provide for 
30 automatic interpretation of the form. Such code can include form identification and 
form template information that comprises at least one attribute for each of a plurality of 
fields. These were described above. 

-11- 
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Form Reader 

Referring to Figure 4 and Figure 1, a form reader process 400 for the form 
5 reader 1 28 will be described. The form reader 128 recognizes form types and interprets 
hand and machine printed text, mark sense (OMR) fields and bar codes, and captures 
zones scheduled for keying (Selective Key From Image (SKFI) zones) on the forms. 
Multiple methods exist to obtain the forms and data for processing at the reader 128. 

1 0 Two of the off-line methods described above enter the PDF form and data to the 

reader 128. The first method is via print and fax 110. A printed PDF form is faxed at 
block 404 to create an electronic image of the PDF form and data. The resulting image 
is sent to the reader 128. The second method is via print and send 112, where the 
printed paper is scanned at block 406 to generate an electronic image. The resulting 

15 image is sent to the reader 128. 

The reader 128 may also be configured to poll directories for received images at 
block 408. Once images are determined to be in the designated directory, they can be 
copied or moved to the reader 128 for processing. 

20 

Another method to receive forms is through a form product Internet solution 
402. such as the TELEform Internet Solution program. Form product Internet solution 
402 sends data to reader 128 for processing, ensuring that regardless of the method 
used, be it print and fax 110, print and send 1 12, or submit on-line 122, the form uses 
25 the same logic and validation processing. What happens to the data and how it is 
handled depends on the form configuration options, which are set when the form was 
designed. 

If the form has no fields or characters needing review when the form is 
30 interpreted, the data is sent directly to a data warehouse 412 and/or auto-exported to a 
predetermined database 410. If the form has characters that cannot be interpreted or 

-12- 
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fields that have failed validation, or are fields designated to always be reviewed, the 
field is marked for review and the form is held for verification at block 414. 



A copy of the form image may also be made and stored to an archive and 
5 retrieval system 416. In the case of a PDF or HTML form, the data can be merged onto 
the form template, creating an image for storage. This can be used for later reference 
by the user. A custom data export option is available at block 418. One final option is 
to create a printed document 420. 

10 

Verifier 

Referring to Figure 5, a form verifier process 500 will be describe. The verifier 
130 is the application used to correct forms. Forms, attachments, and data at block 502 
15 are all input to verifier 130. Attachments are images not classified as forms in the 
system. Once all forms have been corrected and saved, the data and images may be 
sent to a number of devices and/or systems for storage and usage. 

Verified data may be sent to a data warehouse 504, a database 506 or a custom 
20 data export 508. The system allows data to be sent to one or all of the above. Images 
and data may be sent to an archive & retrieval system 512 or printed as a document 510 
if needed. 

25 PDF+Forms 

Referring to Figure 6, a PDF+ Forms format will be described. PDF forms are 
created in the form designer 102 where export selection is made. Once the form 
designer form is completed and configuration settings are set. the form can be exported 
30 at a decision state 604 to create a PDF form 606. 
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In one embodiment, the created PDF form can be distributed at block 608 to the 
user in three different ways. The form may be faxed 610 to a user, printed as a paper 
document 614 and given or sent to a recipient, or mailed electronically 612. The email 
method 612 was discussed above as Email 1 16. 

5 

Forms which have been Emailed or otherwise distributed in the PDF format 
may be filled out at block 616 and submitted at block 620, or partially filled out and 
then printed at block 618, or filled out and re-sent electronically at block 622. If the 
PDF form is partially filled and printed at 618, the form can be forwarded to another 
1 0 user for further completion of the form.. 

Once the PDF form is completed, it can be submitted on-line via a HyperText 
Transfer Protocol (HTTP) on the global computer network or Email at block 622 or 
printed and faxed at block 624, or printed and scanned at block 626. 

15 

PDF Export 

Referring to Figures 7 A and 7B, a PDF Export process 700 will be described 
20 beginning at a start state 701. In the form designer 102, as stated above, a user may 
choose to export a form as a PDF form. When this option is chosen, an attempt is made 
to open the form at a decision state 702. If the attempt to open the desired form fails, 
the process exits at a state 704. 

25 Upon successful opening of the form at decision slate 702. the form is printed to 

a printer driver at state 706, such as PDF Writer or a Postscript driver. In one 
embodiment, the driver is selected by the user. If a PostScript driver is selected, the 
Acrobat Distiller program may be run at state 706 to convert the document from the 
PostScript format to the PDF format. 

30 

After the PDF file is created, an attempt is made to open the PDF file at a 
decision state 708. If unsuccessful, the process exits at state 704. 

-14- 
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Upon successful opening of the PDF file at the decision state 708, a list of 
objects from the form is made at state 712 based on labels embedded in features of the 
form created or modified by the designer 102. This list of objects is generally a list of 
5 fields and groups of fields from the form but can include other features. The object list 
is traversed, one object at a time, in the remaining steps of the process 700. 

Some fields require special fonts for display. Those fonts are generated at state 
714 after the object list has been created. 

10 

A determination is made at a decision state 716 regarding an object from the 
list. If it is not the last item in the list of objects, the process 700 proceeds to a decision 
state 718. A determination is made at decision state 718 as to the whether an. object 
requires the generation of a PDF field, which is a field that is editable in a PDF viewer. ^ V' 
1 5 This too is determined through embedded coding in the designer 1 02 created/modified 
form. If the object requires generation of a PDF field, the object is exported to the PDF 
file. Otherwise, the next object in the list is examined. 

If the object examined at decision state 718 is an object that requires generation 
20 of a PDF field, it is exported and the flow then proceeds to a decision state 720 where a 
determination is made as to whether the object is actually a group of objects. (A group 
of objects contains another list of objects). If the object is a group, then the group's list 
is traversed beginning at decision state 716 in the same manner as the main object list 
for the form is traversed. 

25 

If the object is the last item in the list as determined at decision state 716, 
execution continues at decision state 740 to determine if the object was part of a group. 
If it is part of a group, process 700 continues at decision state 716 for traverse just as 
other groups and the main object list. 

30 

If the object examined at 720 is not a group, then the flow proceeds to a 
decision state 722 where a field template mask is examined. Some fields with a 
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template mask (such as NNN-NN-NNNN for a Social Security Number) may need to 
be broken up into sub-fields. If the field examined at decision state 722 is this type of 
field, process 700 proceeds to a decision state 724 where the first sub-field is identified 
and the process proceeds back to decision state 722. Since sub-fields are not generally 
5 broken up into further sub-fields, process 700 at decision state 722 proceeds to state 
726 for the first sub-field. 

Whether the flow is handling a sub-field or a full field, the PDF field, position 
and properties are generated at state 726. State 726 creates a field that can be overlaid 
10 on the PDF document at the same relative location as where the field exists in the 
designer 102. 

The field or sub-field is examined at a decision state 728 to see if any drawing ; 
code is needed to represent the field accurately. If so, the drawing code is generated at 
15 state 730. 

In either case of decision state 728 process 700 advances to a decision state 732 
where the field or sub-field is examined to see if a pre-fill value is defined for the field. 
This is done when the form designer wishes a field to contain predetermined characters. 
20 If so, the designer assigns this pre-fill value during design for the form. If a pre-fill 
value is defined, the value is set within the field or sub-field at state 734. 

In either case, the flow proceeds to state 736 where any function calls necessary 
to implement validations such as type checking, length checking and range checking 
25 are generated. Such function calls can be derived through a computer program using 
languages such as JavaScript. 

If the object was determined to be a sub-field at a decision state 738, process 
700 proceeds to decision state 724 where the next sub-field is determined. If another 
30 sub-field is needed, process 700 proceeds to decision state 722 and repeats. If another 
sub-field is not needed, then process 700 advances to state 726 where, in one 
embodiment, all of the PDF code and scripts are generated for the parent field of the 
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sub-fields. If the object was not a sub-field or the parent field of the sub-fields was just " 
handled at decision state 738, then process 700 continues at decision state 716 where 
the next field in the current group or the next field in the main form list is examined. 

5 Returning to decision state 740, if the last object was determined at decision 

state 740 to be part of a group, then the group is finished and the next object in the 
parent group or the main form list is examined at decision state 716 and the flow is as 
discussed earlier. If the last object at decision state 740 was not part of a group but was 
instead an object on the main form list, then all of the form objects have been created. 

10 Process 700 moves to state 742 where submit and reset buttons are generated for the 
form. These allow a user who fills out a PDF form and submits it on-line, via posting 
to a server data handling program identified by URL or through Email to do so with the 
click of a mouse or other selection device. Subsequently, all hidden fields and fields 
needed tor control purposes in processing the form, such as the form identification 

15 (1.1X). arc generated at state 744. 

The fields are then sorted at 746 according to the tab order defined in the 
designer 102 so that the same tab order will be honored in the PDF form. Document 
level JavaScript (i.e., not field specific), or other similar computer code, is generated at 
20 suite 74S. T his provides a way for individual field scripts which are used to perform 
validations to call a master program having shared code. Process 700 completes at an 
exit slate 750. 

Referring to Figure 8, exemplary on-screen displays are shown while 
25 performing the steps for exporting a form to the PDF format for one embodiment of the 
invention. 



Conclusion 

Specific blocks, sections, devices, and modules may have been set forth. 
However, a skilled technologist will realize that there are many ways to partition the 
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system of the present invention, and that there are many parts or components that may be 
substituted for those listed above. For example, the export need not to PDF format nor 
viewed by a PDF viewer. Any format capable of being viewed in a web browser and 
written to with overlaid fields can be used. 



While the above detailed description has shown, described, and pointed out the 
fundamental novel features of the invention as applied to various embodiments, it will be 
understood that various omissions and substitutions and changes in the form and details of 
the system illustrated may be made by those skilled in the art. without departing from the 
1 0 intent of the invention. 



-18- 



WO 00/52596 



PCT/US00/05822 



WHAT IS CLAIMED IS : 

1 . A method of creating and interpreting forms, comprising: 

generating a page layout format form having embedded interpretable 

5 codes; 

transmitting the page layout format form a plurality of times across a 
global computer network; 

receiving the transmitted page layout format form at a plurality of 
remote locations from the global computer network; 
10 sending more than one completed form to a central location, wherein at 

least a first one of the received forms has been completed electronically and at 
least a second one of the received forms has been completed manually; and 

automatically interpreting the completed forms by accessing the 
embedded interpretable codes. 

15 

2. The method defined in Claim 1, wherein sending includes sending a 
third one of the received forms that has been at least partially completed electronically 
and at least partially completed manually. 

20 3. The method defined in Claim 1. wherein sending comprises faxing or 

mailing the completed form. 

4. The method defined in Claim 1, wherein sending comprises electronic 
mailing the completed form. 

25 

5. The method defined in Claim 4. wherein electronic mailing comprises 
processing one of the following protocols: POP3. MAPI, or SMTP. 

6. The method defined in Claim 1 . wherein sending comprises transmitting 
30 the completed form via a HyperText Transfer Protocol (HTTP) on the global computer 

network. 
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7. The method defined in Claim 1, wherein the page layout format is Forms 
Data Format (FDF) or Portable Document Format (PDF). 



8. The method defined in Claim 1 , wherein the second one of the received 
forms that has been completed manually comprises completing the form by handwriting 
or hand-printing. 

9. The method defined in Claim 1 , wherein the page layout format is an 
advanced page layout format. 

10. A method of producing a form with embedded codes, comprising: 
generating a page layout format form; 

embedding interpretation codes into the page layout format form 
resulting in an automatically interpretable form; 

transmitting the automatically interpretable form across a global 
computer network to a plurality of remote locations; and 

providing the automatically interpretable form for completion at the 
remote locations, wherein each of the forms is configured for being completed 
electronically, being completed manually, and being completed at least partially 
electronically and at least partially manually. 

11. The method defined in Claim 10, wherein the interpretation codes 
include a form identification. 

12. The method defined in Claim 10, wherein the interpretation codes 
include form template information. 

1 3. The method defined in Claim 12. wherein the form template information 
comprises a plurality of fields, wherein each field comprises at least one attribute. 

14. The method defined in Claim 13, wherein each field includes one of the 
following types of entry data: machine-printed characters, hand-printed characters, 
check marks, filled bubbles, circled responses, barcodes, signatures, or handwriting. 
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15. The method defined in Claim 13, wherein the attributes of each field 
comprise position information. 

5 16. The method defined in Claim 13, wherein the attributes of each field 

comprise field name, type, location, and size. 

17. The method defined in Claim 10, wherein providing includes displaying 
the automatically interpretable form on a visual display screen. 

10 

18. The method defined in Claim 10, wherein providing includes printing 
the automatically interpretable form. 

19. The method defined in Claim 10, wherein providing includes displaying 
15 the automatically interpretable form on a visual display screen and subsequently 

printing at least a partially completed form. 

20. A method of creating and interpreting forms, comprising: 

20 generating a page layout format form configured for being completed 

electronically and being completed manually so as to permit form completion; 

transmitting the page layout format form across a global computer 
network to a plurality of remote recipients; 

providing completion information to the plurality of page layout format 
25 forms received by remote recipients; 

sending at least one electronically completed form and at least one 
manually completed form to a central location; and 

automatically interpreting the entered information on the completed 

forms. 

30 

21. The method defined in Claim 20, wherein automatically interpreting 
includes accessing embedded interpretable codes included on the page layout format 
form. 
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22. The method defined in Claim 20, wherein sending includes sending a 
form that has been at least partially completed electronically and at least partially 
completed manually. 

5 23. The method defined in Claim 20, wherein sending the electronically 

completed form is from a location that is different than a location sending the manually 
completed form. 

24. The method defined in Claim 20, wherein sending the electronically 
1 0 completed form is from a location that is the same as the location sending the manually 
completed form. 



25. A system for handling page layout forms, comprising: 
1 5 a central computer; 

a software program executing on the central computer and being 
configured for interactively creating a page layout format form having 
embedded interpretable codes, wherein the page layout format form is 
configured for being completed electronically, being completed manually, and 
20 being at least partially completed electronically and partially completed 

manually; 

a communications device associated with the central computer and being 
configured for sending the page layout format form across a global computer 
network; and 

25 a remote computing device configured for receiving the transmitted page 

layout format form and for at least partially completing the page layout form 
electronically. 

26. The system defined in Claim 25, additionally comprising an 
30 interpretation program executing on a forms interpretation computer receiving a 

completed form and being configured for automatically interpreting the completed 

form. 
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27. The system defined in Claim 26, additionally comprising a 
communications device associated with the remote computing device and being 
configured for sending the completed form to a central computer. 

5 28. The system defined in Claim 27, wherein the central computer and the 

forms interpretation computer are the same computer. 

29. The system defined in Claim 27, wherein the communications device 
handles a facsimile protocol. 

10 

30. The system defined in Claim 27, wherein the communications device 
associated with the remote computing device handles an electronic mailing protocol. 

31. The system defined in Claim 27, wherein the communications device 
15 associated with the remote computing device handles a HyperText Transfer Protocol 

(HTTP). 

32. The system defined in Claim 26, wherein the page layout format form is 
printed and at least partially completed manually. 

20 

33. The system defined in Claim 32, wherein the completed form is sent by 
a postal service to the location of the forms interpretation computer. 

34. The system defined in Claim 25, wherein the central computer includes 
25 a memory configured for storing the page layout format form. 

35. A system for creating and interpreting forms, comprising: 
a central computer comprising: 

a software program executing on the central computer and being 
30 configured for interactively creating an advanced page layout format 

form having embedded interpretable codes, wherein the advanced page 
layout format form is configured for being completed electronically and 
being completed manually. 
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a communications device configured for sending the advanced 
page layout format form across a global computer network to a remote 
recipient, and 

an interpretation program executing on the central computer 
5 being configured for receiving a completed form and being configured 

for automatically interpreting the completed form; and 
a remote receiver configured for receiving the transmitted advanced 
page layout format form. 

10 36. The system defined in Claim 35, wherein the remote receiver comprises 

a remote computer associated with the remote recipient. 

37. The system defined in Claim 35, wherein the remote receiver comprises 
a communication device configured for sending the completed form to the central 

1 5 computer. 

38. The system defined in Claim 35, wherein the remote receiver includes a 
facsimile function. 

20 39. The system defined in Claim 35, wherein the remote receiver includes a 

mail address. 



25 



40. The system defined in Claim 35, wherein the advanced page layout 
format form is additionally configured for being at least partially completed 
electronically and at least partially completed manually. 
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